Universal Negotiation Forum

ABSTRACT

A negotiation system is disclosed for use in conducting formal and informal negotiations over any subject matter. The system has a web based use interface, which has a dialog board, a submission panel, and a status board. The parties in negotiation can use the web interface to use the server application to manage accounts, negotiation projects, negotiation parties, negotiation rules, history files, and email notification.

This application claims priority from the U.S. Application No.60/782,389 with a filing date of Mar. 16, 2006.

In free marketing society, one of the rights enjoyed by businessentities and people is the right to enter into contract. This right ismore than the right to passively accept an agreement that has beendrafted by another party. This right should include the right toactively negotiate for favorable terms.

Unfortunately, this right has not been fully enjoyed by the people inany nation. In fact, most of the contracts are drafted by one party andoffered to other parties for acceptance. Obviously, the accepting partyis unable to genuinely agree on the terms of the contract. This lack oftrue consent problem is often seen in the enforcement of agreement.Courts often construe a contract against the party who drafts it.

Several factors have contributed to the pervasiveness of lack-of-consentproblem. First, the major factor is the cost of negotiation. The mostpopular negotiation model is that all parties join a negotiationconference and discuss their transaction. The cost for such in-personnegotiation would be prohibitory. Moreover, if two parties negotiateover a transaction, there is no assurance that one or two meetings willresult in an agreement. If two parties are open to negotiation, it maytake several rounds of meetings. This type of negotiation is justifiedonly for use in large business transactions.

Another mode of negotiation is negotiation by mail exchange. By usingthis method, one party drafts an agreement and sends the agreement bymail to the second party for review, consideration and acceptance. Ifthe second party expresses its consent to the agreement, a bindingagreement is formed. Negotiation by regular mail is very time-consuming.At the Internet age, few people have the patience to wait a few businessdays to see an offer or counteroffer. This negotiation mode is rarelyused nowadays.

The parties may also use fax as additional and complementarycommunication means in mail-based negotiation. While faxes are fast andsecure, the receiving party cannot conveniently edit the drafts to makea counteroffer. In other words, the receiving party has to expressdisagreement by independent statements that may introduce additionalconfusion and misunderstanding. The most effective way is always todirectly edit the draft agreement to show the focus of negotiation andpresent the revised draft as a counteroffer. Negotiation by using fax asa communication vehicle may cause a delay. Moreover, fax transmissionmay be unreliable in transmitting a large number of pages of document.Negotiation by mail and fax is improper in a case where the transactionunder negotiation is highly sensitive.

Yet another negotiation method is correspondence by email. This methodhas gained increasing popularity due to convenience, speed and lowcosts. Email is the most dominant negotiation vehicle today. By usingemail, one party first sends a draft to a second party for review andacceptance. If the second party rejects the offer, it may send acounteroffer as an attachment to a responsive email.

There are several problems in email-based negotiation. One of theproblems is security. Negotiations are privileged communication in thecontext of settlement discussion between two adversary parties. If thetransaction under negotiation involves privileged communication, tradesecrets, and potential criminal liability, email is not a propercommunication vehicle. Yet another problem is potential alteration ofemail messages. It is difficult to prove the substance if a partyquestions the authenticity. Due to a variety of reasons, a party may beunable to prove what is in the original messages and drafts. To preventthis problem from happening, parties often send drafts in a non-editablefile such as PDF file. This creates the same problem as in case of usingfax as a communication vehicle. The receiving party cannot edit it andhas to start creating a counteroffer. Yet, another problem is theroutine commingling of private communication with negotiationcommunication. The senders may make comments about irrelevant issues tothe receiving part. Such comments may be harmless in the eyes of thereceiving party at the time of sending, but they may be embarrassing inthe eyes of a public member who reads it many years later.

Negotiation is one of the oldest traditional activities in the humanhistory, but little has changed. Use of faxes has not significantlyadvanced the art. Use of email has promoted efficiency and reduced laborcost, but it has created all kinds of the problems of its own. Yet, fewof email users have realized and foresee the disastrous consequence theymight have to face many years later.

Server based negotiation is not an old concept, neither. It has been thesubject of extensive research and exploration over the years. Aserver-based negotiation forum allows parties to conduct real timenegotiation that is safe and secure. A number of patents have beenissued in the United States. Yet, a major commercial success remains tobe seen. An inherent problem is that the preference of a partyconcerning a transaction cannot be defined to one or more specificparameters such as price, quality of the subject, warranty length, anddelivery method. In reality, a party may reject an offer for any reason.

Negotiation also happens routinely between different members of peoplewithin an organization. When a company has a major legal issue such aspublic offering of stock and intent to tender a firm offer to buy alarge amount of asset, the company must form one voice among its majordecision-makers. Even though this activity is often referenced asinternal review, it is in fact an informal negotiation. Since themembers have different opinions and priority, some members have topersuade others to agree to their positions. Such negotiation mayrevolve about an internal document such as initial public offeringstatement, security filing, press release regarding a milestone and anoffer for the sale of assets.

The subjects of negotiation practically embrace every conceivabledimension of human activities and every phenomenon under the sun. Evenin the legislative and the judiciary branches of both the state andfederal governments, the lawmakers and decision-makers have to negotiatewith other members of the same branch. Moreover, the subjects ofnegotiation are not limited to substantive matters, insignificant thingssuch as writing style, document format, and even the size and shape ofpapers would be a source of disagreement among major members. If acompany wants to launch a major promotional program, the subject ofnegotiation might be the wording of a slogan, a piece of digital voice,and a picture for conveying a program message. Accordingly, protocol forautomatic evaluation of negotiation results has not gained greatpopularity.

All common negotiation methods share several common problems. One of theproblems is that the negotiating parties do not have the sameopportunity to conveniently evaluate the language in draft documents.Neither the drafter nor the reviewer knows how the wording and languagesin the draft affects their substantive right because they do not have anopportunity to study the language that is used in successful agreements.

For example, different clauses are available for use to maintain thevalidity of an agreement when one of other clauses is invalidated incourt. If both the drafting party and the accepting party see othercomparable clauses, they may want to choose a different clause. Before aconvenient negotiation forum is publicly available, it is neitherrealistic nor practical for parties to engage in fair negotiation. It isimpossible for a person to determine whether a warranty statement issufficiently fair to him until the person can review other warrantystatements. It is also hard for an attorney to evaluate each of theclauses without seeing others for comparison.

The dispensing of fairness in negotiation is dictated by the rule ofeconomics: Few people like to spend more money on negotiating a contractthan the price for buying the goods and services underlying thecontract. In a vast number of the “agreements”, especially thoseconsumer agreements, true consent simply never exists. That is preciselywhy vendors can write anything, including a clause that forces theconsumer to pay penalty for every problem originated by the vendor.

The second problem is a lack of systematic method for maintainingnegotiation history files. It is well known that the legislative historyfiles for congressional actions are well preserved. Courts often uselegislative history files of a particular statute to resolve conflictsand inconsistencies in the statute. Negotiation history files areimportant in all cases where the interpretation of the agreement is thekey to resolution of the dispute. Upon to now, no systematic approach isavailable for the maintenance of negotiation history files.

Casual use of email has caused serious trouble in negotiation historyfiles. When parties use email as primary communication means, theparties cannot get identical history files. The first reason is that thecommunication flows back-and-forth and no identical files are possible.The second reason is associated with email delivery system. Some emailmessages might be filtered out or lost in transit while others might beblocked by security measure. The sending party may be unwilling to senda copy if the offer has expired, and problem of expected delay allowsthe sending party a chance to change its mind. Therefore, such fileswill never be available to the receiving party. The third reason is thatemail is for casual use. After two parties have exchanged mail severalrounds, messages quickly pipe up, and it is hard to decipher precisehistory. This problem is worsen by the fact that email program maydisplay messages in different ways and the fact that a responding partymay type in its message between the lines of the original messages.Years later, such messages are incomprehensible to reviewers.

The fourth reason for the email problem arises form archiving andimporting and exporting messages. When messages are archived, the usermay control over how to store the messages. It is possible that some ofthe information is lost during the process. If people work as floaterworkers and have to use email on different computers at differentlocations, they may have to collect their email by importing andexporting methods. Once again, they have only a certain degree ofcontrol over importing and exporting methods. The fifth reason arisesfrom user actions. Some users like to remove email attachments and storethem in folders containing other files. They may edit the attachmentsand save them using the same names. Years later, if a party has torevisit history files, all the party can discover are puzzles such asthe confusion in message flow pattern, lost attachments, all kinds ofinconsistencies and unexplainable time conflicts. For example, if anemail is mismatched with a wrong attachment by a mistake, the reviewerwill have to solve puzzles like a reference to a subject matter that isnot in the attachment, mentioning of an event that had not happened yet,and failing to mention an event that has happened.

After many rounds of sending, receiving and forwarding, archiving,importation/exportation, modifications of attachment files, saving ofmodified attachments, and mixing of detached attachments with otherfiles, it is practically a nightmare to decipher negotiation historieswhich may be the key to the dissolution of an issue. When a controversyarises and an issue is to be decided in court, it is extremelytime-consuming to process emails. For each email, an attorney has toreview it for responsiveness, privilege, and significance. The attorneyalso needs to log all responsive documents into production log, hotdocument log, and privilege document log, if applicable. Due to a largevolume of email and a large number of puzzles that might never besolved, litigation expenses are often prohibitory. The unresolvedpuzzles will directly impact the attorney's ability to effectivelyrepresent the client. The labor costs for processing email can be ashigh as $10 to $40 per piece.

In contrast, negotiation history files should not be maintained in othercases. In a civil case involving substantial potential liability, asettlement negotiation should be conducted without leaving any trace. Ina situation where a party is sued for civil damage and also facespotential criminal liability, it may be preferable that the negotiationhistory files not be maintained by an agreement. Destruction of suchfiles on an on-going basis is a sure measure to prevent privilegedcommunication from getting into its adversarial parties by mistake oromission.

Many businesses, individuals, and law firms negotiate over businesstransactions and documents on a daily basis. Therefore, it is desirableto have a convenient forum that is secure, fair, convenient, intuitive,and cost-efficient. It is also desirable to have a forum, which may beused in real time negotiation. It is also desirable to have optionalresources and controlling mechanisms available in managing thenegotiation behaviors such as the time for expiration of tendered offer,rules on reviving an expired offers, and rejected offers, and themanagement of negotiation history files. All of those devices andfeatures will promote the efficiency of negotiation and ultimatelypromote the spirits of the freedom of contracts.

SUMMARY OF THE INVENTION

The negotiation system (“negotiation forum”) for at least two partieswho negotiate over a subject matter, which may be a document, a concept,process, or an object, the system comprises:

a server connected to Internet through a network interface;

a client computer for each of the parties, the client computer beingconnected to the server by a network connection so that the party canaccess the server;

a graphic user interface between the server and each of the clientcomputers, the graphic user interface containing a submission board, adialog board, and a status board, wherein

-   -   The submission board allowing the party to submit document and        send in message to other members;    -   The dialog board showing and updating the dialog substance of        all the parties, and the dialog substance being shown to each of        the parties; and    -   The status board displaying party identity, the identity of        submitted document, the time of posting each of the tendered        documents, the status board showing to each of the parties; and

Means for declaring a new agreement to each of the parties and allowingeach of the parties to receive a copy of the newly formed agreement.

It is desirable to run this negotiation system securely. The systemallows only the parties in negotiation to view documents andcommunication, but prevents the public from accessing any informationabout the negotiation project.

Optionally, the negotiation system may further comprise a log file inthe dialog board accessible to all parties or means for a party tochange/or reactivate the offer after the offer has been rejected byanother offer. Optionally, the system may also include an emailnotification manager that will send to all parties a message concerningsubmitted documents or statue of the project. It may optionally includetool for managing negotiation history files.

Optionally, the system may have tool for indicating the nature of thepaper as proposal or offer at the time of submission. It may also havetool for distinguishing the status of offer for each of the offers.Optionally, the system may also have a drafting tool, which may be aword processor or a server-based tool fully accessible to all theparties.

The negotiation system of the present invention does not use anymethodology for evaluating the merit of competing offers and proposals.It is a forum for completely open-ended negotiation. It is intended as aconvenient forum to offer unrestricted freedom to its participants.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 shows the basic components of the negotiation system;

FIG. 2 shows the web-based user interface having a dialog board, statusboard and a submission panel;

FIG. 3 shows the account manager for updating account information;

FIG. 4 shows the form for creating a negotiation project;

FIG. 5 shows a project summary displaying owned projects, participatedprojects, and archived protects;

FIG. 6 shows project details for a test project;

FIG. 7 shows one method for adding or inviting participants;

FIG. 8 shows the server's prompt for changing password;

FIG. 9 shows the second method for adding or inviting participants;

FIG. 10 shows one method for joining a project by a party;

FIG. 11 shows the second method for joining a project by a party;

FIG. 12 shows the form for approving or denying pending party;

FIG. 13 shows the form for changing project rules;

FIG. 14 shows preference setup for a project;

FIG. 15 shows the welcome message to a new project member.

DETAILED DESCRIPTION OF THE INVENTION A. The Basic Structure of theSystem and User Interface

The negotiation system (FIG. 1), also referred to as negotiation forum,comprises a server 100 and client computers 130 and 160, all of them arein a network so that they are able to exchange data using common datatransferring protocol such as TCP.

The server 100 is running an operating system 105 and is fullyfunctional, has a network interface 110, and is connected to Internet117 through a router 115. In one of the preferred embodiments, theserver is made an Intel D945PNS motherboard with a Pentium D 820processor being operated by Fedora Core 5. Although the system came witha package of Java tool, a Java Development Kid (JDK version 1.5.06) isinstalled for compiling Java class files. In the ext folder inside thelib folder of the Java Runtime Environment (/usr/share/jdk/jre/lib/ext),activation.jar and mail.jar are placed.

To handle file uploading, a package known as jspsmartupload (orequivalents), which includes several class files, is used. The server isinstalled with Apache Tomcat 5.5.15 and MYSQL 5.0.27, both of which camewith the operating system. To allow Tomcat's Java class component toaccess the MYSQL database, mysql-connector-java.jar is placed inside thelib folder under the common folder of the Tomcat installation folder.The application files of the present invention are placed in one singlefolder with any suitable name.

MYSQL database application (not shown in FIGS) is used for user accountmanagement and for improving the performance in managing the files fornegotiation projects. If speed and productivity is not an issue, it canbe completely dispensed. The concept may be implemented by using Perlprograms and DBM database. Project files, including offers, proposals,attachments, dialog log, and email address list, may be stored inproject folders if no database is used.

The client computer 130 is also operated by its own operating system,has a network interface 135, and is connected to the Internet 117through an interface 140. The client computer 130 has a browser or anysimilar HTML rendering application so it is able to access the server100 using WWW protocol and access the web pages sent by the server 100according to current standard HTTP protocols (1.0, 1.1, and 1.2).

Optionally, a second computer 160, which is also operated by its ownoperating system, has a network interface 165, and is connected to theInternet 117 through its router 170. The second client computer may be avirtual computer residing on the server itself. Negotiation can beconducted between two parties using a client computer and the browser onthe server. Therefore, client computer may also mean a virtual computeron the server.

The application source files developed for this invention include JSPpages and Java class files. The JSP pages are located inside theapplication folder or its subfolders. Compiled Java class components areplaced in the folders under the WEB-INF folder. Inside the applicationfolder, there are two folders, lib and classes. The lib folder maycontain some jar files for run-time use. Within the class folders, theremight be plural class folders with different names, each containing oneclass of compiled Java files. Java components and all jar files must becompatible with the Tomcat application.

In such a system, the JSP will provide all direct interfaces with theuser. The components that are used repeatedly are compiled as classfiles. Under this working system, web page running on browser can accessthe database through the JSP pages or Java classes. All JSP pages andJava source pages are developed gradually. Sine the functionsimplemented in this invention are relatively simple even though it istime-consuming to code.

Whenever a JSP page can run directly under the application folder forumif it complies with JSP syntax requirements. If a Java class file isdeveloped, this file is compiled to form class file first before it isplaced into a proper class folder. The Java class file is compiled usingJavac from Java Development Kit (1.5.06), whose jre/lib/ext containsnecessary API jar files such as mail.jar and activation.jar.

In addition, it is preferable that the server provides a draftingenvironment. In the alternative, the user may draft papers using a wordprocessor such as Microsoft Word, Open Office Writer, or Corel'sWordPerfect on the local computer.

Negotiation often means that negotiation between parties, butnegotiation, in this disclosure, includes negotiation or discussionbetween members of a single party. For example, if a company wants tosettle a case with an adversarial party, it has to reach an internalagreement on what terms the company wants to settle the case. Internalnegotiation may use casual rules.

For the convenience, the documents under negotiation may be referencedto as agreements; they may be other legal paper, advertising design, anproposed marketing program, a photo, a flow diagram, a proposedtrademark name, a price table, a sound file, and practically anythingthat may be a subject of disagreement among members of the organization.Therefore, “agreements” and “draft agreements” are used in thisdisclosure solely for the convenience. They may mean anythingnegotiation subject matter.

This negotiation forum allows the party to make their own choice beforenegotiation starts or change the governing rule on history files in themiddle of game as long as all parties will agree with the change.

B. Web-Based User Interface

The software developed for practicing this invention includes theserver-application and the code for web browser. The main component forshowing dialog board, status board and submission panel viewed from aclient computer are shown in the FIG. 2. This figure shows a testproject under negotiation. On the left top is a dialog board and on theright top is a status board. At the bottom is a submission panel. Threeparties, tester1, tester2, and tester3 are negotiating. All thosewindows are visible to all parties who are logged into the server. Fromthe dialog board, tester1 started with the project and tendered anoffer. This offer was logged on the status board at 1:28.

Tester2 from its own client computer sent a line to reject the offer at1:34. Thus, the original offer is killed. Within the negotiation period,Tester3, however, tendered a new offer, which was logged on the statusboard at 1:39. Tester 2 however sent in a counteroffer at 1:42 and thiscounteroffer was logged at 1:42. Each of the parties can view the dialoghistories and status board entries. They can also view any of theattached files by clicking on it. If a party wants to view 1:34attachment by tester2, one just clicks on the attachment on the leftcell (at the bottom) of tester2 1:34 entry. Each party can view any ofthe offers (which include counteroffers) by clicking on it.

Thus, one can quickly and conveniently review the history files and getclear picture of the on-going negotiation. Since all of the files arekept in the server, one can always accurately reconstruct thenegotiation history files.

Additional features may be added to the status board. For example, allkilled offers may be marked with unique color or icon. In addition,counteroffers may be marked as counteroffer. It is also referable to addan entry on the status board that kill an existing ending offer.

The software on the server includes software modules (or relevant code)for managing negotiation projects, maintaining party identity,displaying negotiation dialog, and displaying negotiation status.Optionally, it has software components or modules for setting up andchanging negotiation rules, managing history files, and sending emailnotification. It is impossible to separate software components basedupon their functions. Solely for the convenience, all the softwarecomponents that jointly perform a unique function are referred to as amanager. The software used in the invention has party identity manager,project manager, dialog manager, status manager, history file manager,negotiation rule manager, and email notification manager.

Each software manager may have different software components or modules,some of which runs on the server (e.g., JSP code and Java code) and someof which runs on the client computer (HTML and JavaScript). For example,the status manager in FIG. 2 has both server side component andclient-site component even though both are originated from the server.The server first creates a bulletin-like window for showing the statusof the negotiation. When a party submits an offer or proposal, thesubmission is performed by the web page, the HTML code, rendered underthe browser even though the web page has come from the server 100. Afterthe information is submitted, the server receives the offer andstatement, and processes the information and updates the status file. Itthen updates the status board by sending an updated web page containingupdated information in the status board to the client computer fordisplay. The status manager contains the code for generating the statusboard, the code of submission panel, and the code for updating thestatus board. It is therefore obvious that some code is shared and usedby many of the managers.

Likewise, the dialog board manager has both server side component andclient component. A HTML, Java or JavaScript program residing on theclient side is responsible for submission of dialogs. When the serverreceives submitted data, it updates dialog log file or database tableand then sends the updated dialog information to the dialog board of theclient computer for display.

A first party gains access to the negotiation server by opening anaccount (the account manager on web page is shown in FIG. 3). The firstparty may click on the project on the account home page to request theserver to create a negotiation project (FIG. 4). Then, the party mayrequest the server to grant privilege to other account holders.

In order to invite a party to joint the project, the project owner logsin and opens Project Summary (FIG. 5). On this page, there are fourtables showing “owed projects”, “participated projects”, “archivedprojects”, and “pending invitations” (some are not visible on the FIG.5). If the owner clicks on “update” at the far right of the test projectentry, the server generates a Project Management Page (FIG. 6) showingthe project details. By clicking on any of the about 10 menu choices onthe left, the owner can change for instance project name, projectpassword, project negotiation rules, and computer preference. If theowner clicks on submit Add Participants, it shows the Add or InviteParticipants to testproject on the right pane (FIG. 7). The owner maytype in the username tester2 and its password of tester2. The secondparty tester2 is granted the right to negotiate in the project. Whentester2 first logs in, it is prompted to change password (FIG. 8). Onthe Project Management Page, if the owner does not know the password oftester 2, the owner may just type username, tester2, and a message (FIG.9). This message may include project ID and password or how tester2 canget the project ID and project password.

When tester2 is logged on, it gets the invitation message. If tester2wants to join the project, it can open its own account summary page(same as FIG. 5). On its project summary page, tester2 clicks on “joinsomeone's project” on the left menu (FIG. 5) and the server willgenerate a page (FIG. 10). If tester2 has been give a project code andproject password by the inviting message or by other means, it candirectly join the project. Otherwise, tester2 can use a second joiningmethod—providing basic information on the right side—and send theinformation to the project owner tester1 for approval (FIG. 11). Anyparty, who is aware of the negotiation project, may also voluntarilyjoin the project by using the same method. For example, tester4 may makea request to join the project. When the project owner tester1 logins andopens the project, he is prompted to approve or deny the request oftester4 (FIG. 12).

After all parties have been invited into the project, the first partystarts the negotiation by logging in the server and drafts a document,written offer or proposal by using a drafting tool or ordinary wordprocessor. The first party types the file name of the document on thesubmission panel or gets the full path-filename by browsing directories(the submission panel on FIG. 2). The first party then submits thedocument for negotiation to the server, and the server then displays theentering of the document on the status board, which will be visible toall parties. The submission party may also enter a comment concerningthe document and submits the comment together with the document. Thecomment will show up on the dialog board (FIG. 2).

It is preferable that an email notification message is sent to the emailaddress of the second party, informing it of the submitted offer by thefirst party. When the second party logs in, the second party can openthe document by clicking on its name/icon and reviews it. If the secondparty accepts it, it just enters a statement in the submission panelindicating its acceptance and submits it. The negotiation ends. Whennegotiation ends, the server will announce to all parties and make acopy of the final agreement available to them. Since email notificationis an art used pervasively on Internet, it is not necessary to discussthe details here.

If the second party does not agree on the document, it may create itsown document, or edit the document of the first party and save it as itsown document (e.g., counteroffer). The second party types in or selectscorrect file path for the document on the submission panel and submitsit to the first party. The second party may also type a statement on themessage window of the submission panel. After submission, the comment isposted on the dialog board with its date and time of entry. Thecounteroffer is stored in a folder or database field accessible to allparties, and an entry is posted on the status board with a link so thatany of the parties viewing the web page can open the document.Preferably, an email notification is sent to the first party of thesubmission of the counteroffer. If the first party accepts thecounteroffer, an agreement is reached. Otherwise, the process isrepeated until an agreement is reached or the negotiation periodexpires.

This negotiation system also provides many options. For example, itallows the parties to set negotiation rules (FIG. 13) such as defaultexpiration period, the option to allow a party to explicitly changedefault expiration rule. The party may also set the rules on how tomanage negotiation history files, when to send email notification, andhow to change originally set rule in the middle of negotiation. Theparty also has an option to submit document as offer or proposal whenthe project is configured for negotiation of contract. The system willmark it accordingly. Finally, the system allows the user to change themessage numbers on display, auto-refreshing time, email notificationpreference, and negotiation mode (FIG. 14). If the refreshing rate ishigh, the system may be used to conduct real time negotiation.

Secured access is highly desirable but not required. Non-secured assessmay be used with or without other digital certificate such as Entrustsecurity (which is used in the website of the United State Patent andTrademark Office's private PAIR).

C. The Software Components for Negotiation Operations 1. Project Manager

The user, who is an account holder, may request the server to create anegotiation project by sending a request to the server. In one of thepreferred embodiments, the basic information needed for a project isshown in FIG. 4. The user is prompted to enter a project name, password,and a description of the project, enter a negotiation period and defaultoffer acceptance period (An offer expires after it passes this period),and select a rule on managing history files.

The system provides four modes of negotiation, which are important forthe negotiation purpose. If the user selects contract negotiation, theserver will enforce many conventional rules governing contractnegotiation unless the user specifically changes a rule, and such achange is reasonable in the modern legal environment. The user mayselect one of four possible negotiation modes. By using matrixnegotiation, the project will allow the other parties to negotiate onlyover a specifically selected terms such as price, delivery term, andwarranty period. If the user selects discussion as the mode ofnegotiation, the system will accept document as proposal (not as abinding offer and counteroffer). This method is especially useful inadopting internal agreement of an organization. It may allow the partiesto extend negotiation period so as to explore the best option possible.

The user may also choose the default offer acceptance period of atendered offer in contract negotiation. If the user chooses discussionas mode of negotiation, then the acceptance period would be the periodfor accepting a proposal.

The user may also select how to manage negotiation history files. Thereare three choices available: keeping history files for permanent record,deleting history file at the end of negotiation, and deleting all filesat end of a round of negotiation. Some more details are provided asfollows:

One of the options is to “preserve negotiation history files forpermanent record”. When this choice is used, all documents andstatements of the negotiation will be maintained for permanent record.At the end of negotiation, all history files will be archived into a zipfile and stored for permanent record. Each of the party may receive thiszip file by download or other means. In addition, any of the parties maybe able to view those files under the browser just like a project undernegotiation.

Another option available is to delete negotiation history files at theend of negotiation. When this option is selected, the server will deleteall negotiation files at the end of the negotiation. Negotiation endswhen a contract is reached, a proposal is adopted, or when negation isaborted due to expiration of the negotiation period.

Another option is to “delete history files at the end of a round ofnegotiation”, and this option is useful in the negotiation over the mostsensitive subjects such as civil lawsuit, plead bargain, and deals thatmight be in violation of laws due to unsettled laws. A round ofnegotiation is considered to be at end when the parties have reached anagreement, the initial offer expires, or all the parties have viewed thepending offer but failed to reach an agreement. Thus, the server willdelete all history files (but not the final agreement) when the partieshave reached an agreement. If one or more parties have not responded butthe offer expired at the end of expiration period of the offer, theserver will also delete the history files. If at least one party hasrejected the offer, and all parties have accessed the pending offer, theserver will delete the history files. By selecting a sub-option which isto be implemented, the party may ask the server to delete history filesonly after all parties have an opportunity to view a pending offer eventhough at least one party has rejected the offer. If the negotiationperiod ends, the server will also delete all history files, regardlessof negotiation outcome.

When the history files are preserved for permanent record, the servermay use the project password to make a zip file so that only the partieswho know this password can open the history file.

After the user sends the project creation form, the server thengenerates a project ID, which might be a numeric string or an ASCIstring. It also creates the following items:

-   -   1) At least one public folder for storing project basic        information, proposals and offers, dialog file, attachments to        the dialog, and schedules (e.g., attachment to an offer and        proposal);    -   2) Log file for storing the dialog of all party on the dialog        board,    -   3) A file for storing information on the status,    -   4) A file for storing the basic information about the project.    -   5) Optionally, a file for storing email address list used for        sending email notification.

Those files, collectively known as project data files, may be stored inthe same folder or in one or more subfolder within different accessprivileges. Preferably, for the safety and reliability they are placedin a project folder or its subfolders, which can be accessed only by theparties in negotiation. The files may be stored in any folder and theiraccess privilege may be controlled by access permissions. If thenegotiation server is operated by a Unix or Linux operating system, theproject folder and its subfolder will be readable by all the parties innegotiation (e.g., using a group permission).

The project data may be written into database tables; therefore, projectdata files also mean the relevant database tables throughout thisdisclosure when a database is used.

In one of the examples, the steps necessary for creating a project are:

-   -   1) A party makes a request for setting up a project;    -   2) The system generates a project identity which may be a code        or a string;    -   3) Create a folder which may include one or more subfolder for        storing copies of all of the proposals and offers;    -   4) Use the party name as the owner of the project files and        folders;    -   5) All parties of the project are assigned with the group id        (may be identified by the project name or code), and grant group        access privilege to project's folder and subfolders;    -   6) Create an empty dialog file, which can be read by all the        parties in the group in a way controlled by the dialog manager;    -   7) Create an empty status file, which can be accessed by all the        parties in the group defined by the status manager.

A negotiation system at elementary level may be built to host a limitednumber of negotiation projects. To show the concept of this invention,there is no need to use database. However, database implementation hastwo advantages. It can handle a large number of projects and their filesefficiently, and it allows users to search their files quickly. To hosta large number of user accounts, it is preferable to use a databasetable. Account management art is used everywhere on Internet. Detaileddiscussion of database table usage is focused on functions, which areunique.

When the project data is saved in the tables of a database, the tables(Appendix B) holding project data is equivalent to the project folders.Many of the fields are self-explanatory in light of the FIG. 4. “type”holds information about the type of negotiation project, and the“activated” holds the information whether the project is pending oractive for negotiation. “Negotiationmode” holds information whether is areal time negotiation (FIG. 14). When the server is called to display aproject for a project ID, the project manager uses the information fromthis table to decide how to show the project on all relevant pages.“Notity” holds a flag indicating whether a notice should be sent to allmembers of the project when a change in any aspect of the projectoccurs. “Activated” is used indicate if a project is active fornegotiation or pending during the creation period (see project summarypage on FIG. 5).

In one of the preferred embodiments, a projectmembers table is used tokeep track of the members (Appendix C). This is equivalent to grantthose members the right to access all project data. When a member islogged in and authenticated to be a member of a project, the serverknows this status by using a session object. Thus, it is unnecessary toauthenticate the member on every web page the member visits. All of themember names for each project and some relevant information are storedin this table. The server can identify all members by the project ID orby the membername. Lineperpage is the number of message units to bedisplayed to the parties on one screen page. In this table, prjid holdsproject ID. Firstlogin is used to keep track of whether this memberlogs-in first time, and it may cause the system to display someimportant message or warning such as asking if the party wants to changethe negotiation rules (See FIG. 15). “Notify” is used to signal thesystem to display a message when the party accesses the project.

In one of the preferred embodiments, the table projectboard (Appendix D)is built to hold dialog statements, offer, the number of attachments tothe offer, and the number of attachments to the dialog for eachsubmission. The field “dialog” holds the dialog statement; “id” holdsthe submission id. Dattachment and oattachment signal if this submissioncontains an attachment to the offer and an attachment to the dialogstatement. Prjid, membername, and id are indexed so that the server canefficiently find any submission by prjid, membername, and submission id.Attachments to the offer and the dialog are not stored other tables.

In one of the preferred embodiments, the table offerpoll (Appendix E) isused to keep track of each of the offers and determine if the offer isstill valid. “id” in this table is for the identification of offers. Ifan offer is rejected by any of the negotiation parties, the offer ismarked as invalid, and will be ignored in the subsequent negotiation.Such offer entries may be kept as history files.

In one of the preferred embodiments, a table dialogattachments (AppendixF) is used to hold dialog attachments (see the attachment shown in FIG.2). The dattachments field in the table projectboard contains the numberof attachments. An entry to the table is made only when this number isnot zero. In retrieving the project data, the server will search tabledialogattachments only when it finds that the value in dattachment is apositive integer. Similarly, table offerattachments (Appendix G) is usedto store attachments to an offer. Since some of the offers may betendered without attachment so this implementation will save disk space.

In one of the preferred embodiments, a table pendingmembers (Appendix H)is used to store information on pending parties. This table keeps a listof pending parties for each of the projects. This table also containsthe information about the pending member's email address, real name, anda message for each pending member.

In one of the preferred embodiments, the table pendingprojects (AppendixI) holds information about the owner username and real name, and emailaddress, and message. A project is pending after it is created until itis activated for negotiation.

In one of the preferred embodiments, a table changeprojectrule (AppendixJ) is used to keep information on the new rules proposed by anegotiation party. “closeddate” is the date the negotiation period ends.“offerexpiredunit” is the unit for offer acceptance period stored in thefield “offerexpired” is day, month or year. Its use is clear when it isviewed in light of FIG. 13.

The table changeprjrulepoll (Appendix K) is used when a party of projectwants to change negotiation rules at the middle of negotiation. For agiven project, each of the parties will vote if it agrees to the newlyproposed rules. If a party rejects the new rules, no further action willtake place with respect to the new rules.

The following table archivedprojects (Appendix L) is used to mark theprojects that have been archived. Archived projects are shown in FIG. 5(the whole archived project table is outside the margin). The table on aweb page would look like the table for participated projects.

When a database is used to hold offers, attachments to the offers, andattachments to dialog statements, each of the entries is uploaded to afolder for temporary storage, and then written into the right field of adatabase table. The steps for submitting a text string are described asfollows:

-   -   1) The party types in a string in the in submission panel;    -   2) The server gets the value of the string;    -   3) The server verifies the identity of the person and the        project ID.    -   4) If the system uses common encryption method, server encrypts        it.    -   5) The server writes the string into the corresponding field of        the database table projectboard and dialogattachments and        offerattachments if attachments are present.

There are two ways to encrypt the files and dialog statements, dependingupon what encryption key is used. The server may use a common encryptionkey for encrypting all of the files. Thus, the server administrator anddata warehouse staff will not be able view any of the files. However, itis still possible that some people who know the common key may be ableto decrypt the files. For increased security, the server may use aprivate encryption key, which may be the project password or a specifickey known only to the parties in negotiation. This key itself may beencrypted and stored in a key database. Regardless of the difference inkey, the general steps for encrypting a file are as follows:

-   -   1) If a file is updated by using a file uploading method, the        file is first uploaded to a temporary folder and is saved there,        the server also saves information on the file type;    -   2) The server then retrieves an encryption key which may be        saved in a key database or any other suitable table in the        project database;    -   3) The sever then encrypts the file using the retrieved key;    -   4) The sever saves the encrypted file in a project folder or        writes the file in a proper field of a database table;    -   5) The server finally deletes the original file from the        temporary folder.

The files saved in the project folder or stored in a project databasetable are not readable by humans. When a party wants to access a file,the general steps for downloading file are as follows:

-   -   1) The server generates a link on a web page for downloading the        file, the link contains file type information;    -   2) A user clicks on the link;    -   3) The browser makes a request for downloading the file from the        server;    -   4) The server retrieves the file from a folder or retrieve the        file from a database field holding the file;    -   5) The server then retrieves the encryption key;    -   6) The server decrypts the file on fly using the key;    -   7) The browser opens the file if the file can be opened by the        browser; or prompts the user to save the file on the local        computer if the file cannot be opened by the browser;    -   8) The user then opens the file using a proper application.

Optionally, the system may provide a private storage folder to eachparty who chooses to use it regardless of whether a database is used.The security of private files is important. For the maximum security,the server may keep all files in an encrypted form. Each of the partiesmay encrypt files using its own assigned key. Many encryption algorithmsare well known. One of them is Blowfish (designed in 1993 by BruceSchneieris), which takes a variable-length key, from 32 bits to 448bits.

When encryption is properly used, the parties have sole responsibilityto securely keep the key permanently. If the key is lost, the content ofprivate files cannot be recovered. For an important project, such theencryption key should be stored in a third party without disclosing itsuse and is recoverable in the event of loss. Whenever a party wants tosave a file in its private folder, the request contains an encryptionflag and a private key. The encryption key itself should be encrypted.Before the file is saved, the file is encrypted and then is written tothe disk of the server.

In retrieving the file, the party sends a request together with the fileencryption key. After the file is read, the system then decrypts thefile before it is sent to the party on a browser. The server will notsave the key.

The parties may also have an option to encrypt the group's folder forthe negotiation group, preferably, using project password.

2. Party Manager

In an implementation without using database, party management is simple:each of the group can access only the project files of the project.Party identity may be managed by shell accounts under Linux operationsystem.

If this negotiation server is used to host a large number of negotiationprojects, database user table (Appendix A) may be used to manage useraccounts. This table is like other frequently used user tables exceptthat it has a warning field. This field is used to provide a warning ifits password is used by another negotiation party.

Party manager allows any of the parties who are the existing accountholders of the negotiation server to grant access privilege to one ormore negotiation parties. The two preferred methods are (1) associatingan existing account with an existing project and (2) creating a guestaccount by the existing account holder for another negotiation party.

(1) Association of an Account with an Existing Project

If a first party makes a request for associating the account of a secondparty with a created project, the server prompts the party to enter login information about the second party, the email address of the secondparty, and the project code. If the first party enters a correct loginname, the email address, and project code, the system grants accessprivilege for the project to the second party. When the second partyfirst accesses the project, it will be required to verify its identityand to send some basic information such as real name and contact addressto the first party for verification. If for any reason, the first partyfinds that the second party is not a right party, the server will revokethe privilege from the second party. Negotiation privilege will befinally granted after the first party successfully confirms the identityof the second party.

In one of the prospective examples, the steps for associating an accountwith a project are as follows:

-   -   1) The first party makes a request for associating an existing        account with an owned project;    -   2) The party manager prompts the first party to enter project        identity, login name, email address, and the name of the second        party, the information is saved in table pendingmembers, and    -   3) If all information is verified, the party manager will grant        the access privilege to the account to be associated, and grant        group access privilege to the second party so that the second        party can access all the project files; in one of the preferred        embodiments, the membername together with other information is        written into the table projectmembers.

If the first party only knows the email address of the second party, thefirst party may send an invite using the email address and projectidentity only. The server then searches for the login name associatedwith the email address. If no such account exists, the server willinform the first party of the non-existence of the account, and ask thefirst party to assign a guest account to its intended second party. Ifthe email address is valid, the server sends a message to the secondparty, inviting it to login in. When the second party logs in, it isprompted to express whether it wants to join the negotiation. If itanswers affirmatively, the second party is prompted to enter name andcontact information and the server sends the information to the firstparty for verification.

In one of the prospective examples, the steps necessary for associatingan account with incomplete identification information are as follows:

-   -   1) The first party makes a request for association of an account        with an owned project;    -   2) The party manager prompts the first party to enter project        identity, the login name, email address, and the real name of        the second party;    -   3) If the first party enters only email address associated with        the account to be associated;    -   4) The party manager marks the account as unverified account;    -   5) If the email does not exist, notify the first party that no        account exists.    -   6) If the email address is used by an account holder, the party        manager sends email to the second party inviting it to join the        negotiation, the notice may be sent by regular email or web        email;    -   7) When the second party logs in, the server prompts the second        party to verify its identity, including it own true name and        contact information;    -   8) The sever then sends the identity information to the first        party for verification; when the first party is on-line, it        sends the identify information to the first party and prompts it        to confirm whether the identity of the second party is right;        and    -   9) After the identity being verified, the server grants access        privilege for the project to the account of the second party.

If the first party is able to provide login name, associated emailaddress, and name of the owner of the account holder correctly, theserver may grant access privilege to the second party without furtherverification. If the first party knows both the login name and passwordof a second party, the server will also associate the account with theproject directly. In this case, the server will prompt the second partyto change password (see FIG. 8) when the second party logs in the nexttime. When the password of the second party is disclosed to the firstparty, the server puts a mark on the warning field of the account recordof the second party. So, the server displays this message.

Many more subtle variations in authentication are available as long asthey will not compromise the security of the project data and will notinfringe the privacy and safety of each of the party accounts.

Only the owner of a project has the right to associate an account of asecond party with the project, it is equivalent to associating the twoaccounts through the project. For the convenience, it may be viewed asassociating two accounts.

(2) Assignment of a Guest Account

If a first party wants to negotiate with a second party who is not anexisting member of the negotiation server, the first party may assign aguest account for the second party. After the first party chooses thisoption in a properly displayed menu, the first party is prompted toassign a user name, a temporary password and project id. The system thencreates a guest account and associates the guest account with theaccount of the first party. The guest account is marked as anunidentified account. When the second party logs in the guess accountfor the first time, the second party is prompted to provide its identitysuch as name and contact information. Moreover, the second party isprompted to change the password so that the first party cannot accessits private folders. After the creation of the guest account,preferably, the system sends an email invitation to the email address ofthe second party. This message may have a link to the guest account sothat the second party can directly log in by clicking at the link. Whenthe second party logs in the first time, the second party is prompted toprovide real name and contact information, and the server sends theinformation to the first party for verification.

If the first party confirms its true identity, the server will make thesecond party a party of the project group, and grants privilege foraccess the project.

In one of the prospective examples, the general steps for making a guestaccount are summarized as follows:

-   -   1) The first party makes a request for assigning a guest        account;    -   2) The party manager prompts the first party to enter proposed        account login name, a proposed password, together with the        project identity and recipient email address, the account        information may be generated by server automatically;    -   3) The sever creates an account by creating a private folder for        the second party or an entry in the user table;    -   4) The server records the password as the provisional password        and marks the account as an unverified or unconfirmed account;    -   5) The server sends an email invitation to the second party;    -   otherwise, the first party must give an account information to        the second party;    -   6) The second party logs into the new account the first time;    -   7) The server prompts the second party to provide its true name        and contact information, and change the password;    -   8) The server receives a new password, the real name, and        contact information from the second party;    -   9) Optionally, the server sends the real name and contact        information to the first party for further verification;    -   10) If the first party confirms that the identity of the second        party is correct, it will grant the access privilege to the        second party. Then, the server marks the guest account of the        second party as verified;    -   11) The server then compares the new password with the old        password in file. If there is a substantial difference, the        server marks the account as ready. Otherwise, the server will        send another email to the second party, prompting it to change        its password again; and    -   12) Upon successful confirmation of the guest account and change        of password, the server marks the account as a confirmed        account, which is ready for negotiation.

3. Negotiation Rules Manager

After a negation group is established, the parties may agree on certainrules governing the negotiation. The negotiation will be governed bywhat are known as “governing rules”. The system provides a set of ruleswith default values (FIG. 13) and the parties can change the defaultvalues of the rules by agreement.

The Project Management Page (which includes practically all softwarecomponents) has the option to change many of the rules. Those rulesincludes the following:

-   -   1) The acceptance period within which an offer may be accepted;    -   2) The right to retract an unaccepted offer before it expires;    -   3) The deadline to terminate the negotiation;    -   4) The right to overwrite a governing rule at the time of        submission; and

For each of the choices, the system will have a default values (FIG. 13)and the table changeprojectrule (Appendix J). If an offer is tendered bythe first party, but not accepted by the second party during theacceptance period, it expires at the end of the period, and cannot beaccepted later by any party. The value for acceptance period in thistable can be changed. The default rule for retraction (not implementedin the table changeprojectrule) is that a party may retract an offerbefore it is accepted. The default rule for negotiation deadline isinfinite. The parties may set a time period as negotiation deadline.They may also agree whether the default rules can be overwritten byspecific instruction of a party at the time of submission. If this isallowed, a party may indicate at the time of submission that the offerwill be expired sooner or later than the time period set in thegoverning rule.

After the project negotiation starts, a party who accesses the projectthe first time, will be prompted to express whether it wants to changedefault rules. If the party does not want to change default rules, theparty will be allowed to proceed by clicking on Next (FIG. 15). However,the party is reminded that other parties may want to change negotiationrules when they sign in the project the first time.

If the party elects menu to change default rules, it will be promptedwith a menu allowing it to change negotiation rules (FIG. 13). After thefirst party makes the choices, the system then informs the second partyif the second party will agree with the selected new rules the very nexttime the second party logs in. The proposed rules, e.g., the substanceof the rules, are stored in the table changeprojectrule (Appendix J)while the voting record is stored on table changeprjrulepool (AppendixK).

If the second party does not agree, the system will inform the firstparty that the request for changing rules has been rejected andnegotiation could continue according to governing rules which is mostlikely the default rules. The system may allow the first party to revisethe rules in one or two more attempts. If no agreement can be reachedregarding negotiation rules, the negotiation will proceed according togoverning rules of the system. The system will enforce governing rulesthroughout the negotiation.

If the second party agrees with the changed negotiation rules, thesystem will accept the rules, and conspicuously displays the modifiedrules on the negotiation side penal or anywhere they can be viewed byany of the parties in negotiation. The system may also have a menu,which allows the parties to change negotiation rules at any time,effective prospectively. The rules can be changed as long as all partiesagree and the system will enforce newly agreed rules prospectively.

In one of the examples, the steps necessary for implementing the stepsfor changing negotiation rules are:

-   -   1) A first party is prompted to change governing rules.        Optionally, the prompt contains message that informs all the        parties that they have limited rounds of negotiation for        changing governing rules. If they fail to reach an agreement on        adopting new rules, negotiation will proceed according to the        existing governing rules.    -   2) The first party is prompted to select different values for        governing rules.    -   3) After the first party submits proposed rules and the values        are saved on a table like the table changeprojectrule (Appendix        J). The system sends a notice to the second party for consent,        and the notice will display the proposed governing rules chosen        by the first party.    -   4) If the second party agrees and confirms it, the system uses        the proposed rules to overwrite then governing rules in the rule        file or the table project to the extent they are applicable; if        the parties cannot agree on the proposed rules, the system will        prompt the parties to propose new rules starting from the party        who rejects the proposed rules or ask the first party to revise        its proposed rules, repeating the process from step (3).    -   5) The system enforces using the rules on the rule file or the        table project;    -   6) The system enforces the governing rules in all future        negotiation processes until one party makes a request for        changing the governing rules and the remaining parties agree to        the change. If the parties are unable to agree to new rules in        the allowed attempts, the system will allow the negotiation to        proceed according to original governing rules.

If there are more than two parties in negotiation, when a party proposesnew rules, it is adopted when all of the parties agree to the proposedrules. However, if at least one party disagrees with the proposed rules,the proposed rules are killed. However, at any point, the parties mayagain to propose new rules and repeating the process.

4. History File Manager

This component of the software allows the parties to set up rulesgoverning maintenance and disposition of negotiation history files. Theoptions on web page are shown on FIG. 13. In the preferred embodiment, afield, historyfiles, is used in the table projects. The system will usethis value of this field to enforce the rules throughout the negotiationprocess. There are several ways of implementing this rule.

First, the project owner who sets up the project has the option toselect how to manage history files. Second, after negotiation starts,any of the parties may propose to change the rules governing historyfiles enforceable prospectively to the extent possible.

The system provides means for negotiate over the rule governing themanagement of history files in the same way as for changing othergoverning rules. In one embodiment of the present invention, the processfor changing the negotiation rules is as follows.

A first party makes a request that the history file be maintained. Therequest is written in the table changeprojectrule (Appendix J).

Upon the consent by the second party, the system will manage historyfiles according to their agreed new rules. System will save all historyfiles such as dialog log, the status table file, all rejected proposals,rejected and expired offers, and the final agreement and any other filesin the project folder. If the parties are unable to reach agreement onnew rules governing history files, the system will continue to use therule that has been selected by the project owner.

In the example of the present invention, the parties may elect to havecontrol over how to manage negotiation history files. In this case, theparties may electively keep negotiation files such as dialog log,rejected proposals, rejected/expired offers, and the final agreement.The parties may delete some of them selectively. What is important isthat the rule is placed before the starting of negotiation. The systemwill not allow the parties to change the rule in the middle of the gameas to the earlier history files. Of course, the parties may reach a newagreement as to how to manage history files prospectively. If allparties agree, they can change the system's management of history filesprospectively. In a prospective example, the server may generate a pagecontaining a list of the choices as follows:

1. Dialog statements:

-   -   a. [ ] deleted at the end of each round of negotiation.    -   b. [ ] deleted at the end of the negation period.    -   c. [ ] kept for permanent record.

2. Dialog attachments (not part of offer or proposal):

-   -   a. [ ] deleted at the end of each round of negotiation.    -   b. [ ] deleted the end of the negation period.    -   c. [ ] kept for permanent record.

3. Draft documents such as offers, counteroffers, or proposes and theirattachments:

-   -   a. [ ] deleted at the end of each round of negotiation.    -   b. [ ] deleted the end of the negation period.    -   c. [ ] kept for permanent record.

4. Last five draft documents such as offers, counteroffers, andproposes:

-   -   a. [ ] deleted at the end of each round of negotiation.    -   b. [ ] deleted the end of the negation period.    -   c. [ ] kept for permanent record.

If those options are implemented, the historyfiles field in the tableprojects needs to be replaced by four fields so that different values ofeach of the fields can represent three or more choices.

The system also allows the parties to set up a rule on managing historyfile in the event that the negotiation breaks up or deadline is reachedwithout reaching an agreement in a way different from the case when anagreement is reached. In this case, a different value in historyfilesfield may be used.

Optionally, at the closing of the negotiation, the history managergenerates a statement or summary concerning the negotiation history inplain language. This summary can show a clear picture of the processthat the parties submit their offers and proposals before they reachedthe final agreement.

In the case that the parties elect to delete history files at end ofeach round of negotiation. The system will delete dialog statements,offers and proposals at the end of each round of negotiation or, in thealternative, immediately after they are rejected. The server keeps andshows only offer or proposal that has not been rejected or the finalagreement.

In a prospective embodiment of the present invention, if the projectowner and the parties choose to preserve negotiation history files, thesteps for maintaining history files are as follows:

-   -   1) After the parties agree on the rules on maintaining        negotiation history files, the system keeps this rule in a file        or in the table projects (Appendix B) and enforces it;    -   2) If the party selects to keep all history files for permanent        record, the server will save all offers or proposals, schedules,        and attachments according to the rule;    -   3) At the end of the negotiation, the history file manager will        make a copy of the entire file folder for the project, produce a        password-protected zip file, and make it available to each of        the parties for downloading; If the project files are maintained        in a database, the history file manager will retrieve all of the        files with the project ID and save them in a project folder with        or without subfolders, and produce a password-protected zip        file, and make it available to each of the parties for        downloading; and    -   4) The system may permanently archive a copy of all project        files for its own record for a period of time.

If a third-party vendor hosts the negotiation, all negotiation historyfiles and folders are preferably not viewable by the vendor who providesthe services. To achieve this end, the negotiation files may beencrypted using a key that is known only by the parties in negotiationas discussed under Project manager.

5. Dialog Manager and Dialog Board

The dialog board, viewed on a client computer display, is shown in FIG.2. The submission panel works together with the dialog board, it is moreconvenient to describe them together.

Dialog board at the server may be a file for storing the dialog in text.The dialog manager allows a party to write text on the submission panel,to submit it, and cause the server to append it to the file. It has twocomponents: Part of it is in the user interface, which is just relevantHTML or JavaScript code in the submission panel. From web page view, itis a form with some editing functions.

After a party edits a text, the party then clicks on a submission buttonto submit it.

The functions of the submission panel are (1) indicating submission typesuch as proposal, offer, acceptance, retraction of an early offer, (2)submitting schedules (e.g., attachments to offers and proposals), (3)submitting attachments for the dialog; and (4) serving as signature ofthe submission so that the submission has the effect of consent orrejection.

The submission panel may contain options for (1) shortening or extendingoffer acceptance period, (2) sending an email notification to otherparties, (3) uploading signature image, and (4) choose to usingadditional security features for authenticating the submission.

Some of the functions on the submission panel are shown in the FIG. 2.The party may be prompted to enter its data at prompt if they are notshowed on the submission panel. The submission panel may use JavaScriptfunction confirm the submission or conduct formality check.

On the submission panel of the preferred embodiment, a default value 30(e.g., 30 days is an acceptance period and the 30^(th) is the expirationdate), which is consistent with a governing rule, is printed on the textinput box. If the party does not enter any specific data to overwriteit, the default 30-day acceptance period will be used by the system. Thesubmitting party may override it and change it. However, the right tooverride it may be preempted by the governing rule of the project. Ifthe party has disabled this right in the project setup, then thoserelevant fields are inactive. Additional feature may be added to useprivate security certificate.

If the submission party chooses to include an attachment to the dialog,the web page component of the dialog manager will prompt the party tofind the attachment and includes it on the submission panel using aproper file name and path. If the submission party chooses to include aschedule that is part of an offer or proposal, the party will beprompted to find the schedule and include it on the submission panel.The submission party may include as many schedules and attachments asthe party needs unless the server impose limit.

After the submission panel is ready, the party presses the submissionkey to submit the data. The system optionally prompts the party toconfirm that the information is correct. Upon the final confirmation,the dialog manager will send the dialog to the server and appended thedialog text into the dialog file in the project folder or a databasefield like the dialog field on table projectboard (Appendix D). Theclient computer also uploads the offer, the attachment to dialog, andthe attachment to the offer to the server, which will save them inrespective project folders, or in a temporary folder and then write themin proper database fields like the offer field in projectboard (AppendixD), the content fields in table offerattachments (Appendix G) anddialogattachments (Appendix F).

The server through the status manger updates the status board byentering the newly entered offer or proposal together with the scheduleto the status table. It then updates the status board for the party whomakes the submission. However, the server will not refresh the screenviews of other parties who happen to be online. Their screens arerefreshed by automatic refreshment of a loaded web page. The timing ofautomatic refreshment is setup in the preference (FIG. 14).

For an intensive real time negotiation, it may be desirable that dialogfile is loaded in a variable in memory (like a session object). This canspeed up updating and sending speed. The system may set a time periodfor keeping the file in memory just like a session object having activelife. Because the server might have multiple negotiations, each of theobjects should be identified by a unique name such as the project ID.Each of the submissions contains this project ID, its own id, and nameof the submission party. If no project ID is used, the sever may findthe project ID from the account identity of the submission party if theparty attended only one project. When the server receives a newsubmission, it identifies the submission using the project ID, its ownid and the party name, and matches the submission with a variableholding the dialog information and updates the substance in thevariable.

6. Status Manager and Status Board

The status board, viewed at a client computer, is shown in FIG. 2.

The submission panel works together with the status board so it isconvenient to describe them together.

A party, who submits an offer, needs to indicate final consent by typingits e-signature such as /s/ (see the submission panel). Preferably, sucha newly submitted offer or proposal should be distinctively marked witha unique icon or color on the status board so that a submitting partycan easily see an inadvertent mistake right after submission. It ispreferable to provide an opportunity to retract a submission that hasbeen submitted by mistake.

When a party uses this negotiation forum, it drafts an agreement, viewthe dialog board, or view the negotiation status board. The status boardshows following essential components: parties' identities, offeridentities, and submission dates. In addition, the party is able tolocate and open all submitted documents conveniently.

In one of the preferred embodiments (FIG. 2), the status board may showthe parties' identities at the top in parallel. The left column showsthe submission date of each offer or proposal. Each of the offers isshown on the table, and each of the submitted schedules is alsodisplayed right next to the offer on the table cell (no schedule wassubmitted for the test protect). If the party clicks on any of theoffers or schedules, the status board will prompt the server to downloadthe file directly for online review. This feature will allow any of theparties to instantly access any of the offers, proposals, and schedulesby clicking its name. In the alternative, the status board may bearranged in other suitable format.

Preferably, an icon in unique color may be used to display the link foreach of rejected offers and proposals. The system may also use two ormore distinctive colors, respectively for rejected offers and proposals.Additional notations and color may be used. Therefore, the statusmanager needs to determine if an offer or proposal has expired or hasbeen rejected. An offer is rejected if another offer has been tenderedor if it was expressly rejected by at least one party.

To avoid the possible confusion when a party submits a dialog withoutcounteroffer, an additional field, “consent”, is added in the tableprojectboard (Appendix D). When a party submits a statement withoutcounteroffer or submit a proposal without a counteroffer, the server maybe unable to understand its decision to the pending offer. Therefore, itis preferable that the party is prompted to check a box if the partyaccepts or rejects the pending offer. If the party accepts the offer,the party checks on yes. After a submission is made, the server thengets the value for this box and writes it into the “consent” field in aproper format (e.g., N for rejection, I for inaction, and Y forconsent).

When a party submits in an offer, the server automatically marks the“consent” field with “N” in the projectboard table. Each time when aparty in a negotiation project makes a submission, the status manageralso transfer this value to the field “decide” in the table offerpollwith respect to a pending offer. By using the projectboard record, thestatus manager will determine if a valid contract is formed by lookingat the values of in this field for all records associated with theproject since the pending offer was posted. If the status manager findsan “N”, it treats that pending offer as rejected. If it finds that allparties in the project have marked “Y” within the expiration period, acontract is declared. If the status manager finds only some members haveexpressed consent but it has passed the negotiation period, the statusmanager will also declare the end of the negotiation.

The status manager may also use the table offerpoll to determine if acontract is formed. Each time when a party makes a submission, itsdecision on consent or rejection is written in the “decide” field (e.g.,0 for inaction, 1 for rejection and 2 for consent). The offer postingdate is available in the table projectboard. Optionally, an offerpost-date field may be added in the table offerpoll so that the statusmanger can determine negotiation status without using tableprojectboard.

On the server side, the negotiation status information may be saved in aformatted file like an Excel table. If there are n parties, there shouldhave n columns. The matrix should be able to hold a sufficient number ofentries the parties may enter in the entire negotiation period. There isnothing on the left column. When a party submits an offer or proposal,the system gets the time and date from the server and enters the dateand time on the left column right below the party identities or the lastsubmission entry. It prints file's path and name. Before any offer orproposal is entered, the table is empty except that the top row hasparty identities. To present the data to the party at client computer,the status manage just reads this formatted data, and use the data tobuild the status board using table format, converting the file pathsinto links so that the party at the end can download the offer.

In one preferred embodiment of the present invention, the statusinformation is written into the table projects. “offer” is a link,which, upon being clicked, causes the server to find the offer file fromthe “content” field of the table offerattachments and has it downloadedto the client computer. One sample link is <ahref=“downloadoffer?id=2&membername=tester2” target=“-blank”>Offer</a>

Use of different colors and icons on links on a web page is very simpleand straight. Since the status manager can determine the status of eachof the offers and proposals, it can use different fonts and colors orimage icons when it prints links on the status board for the offers andproposals. In addition, in a prospective embodiment, a link may be builtbetween any offer on the status board and the related dialog entry sothat when a party clicks on the offer, the color in the relevant messageblock of the dialog board will change. The party can easily find therelated statements for each of the offers.

The status manager enters the filename in the cell crossed by thedate/time and the identity of the submission party. While the statusmanager may use any filename used by the submitting parties, it ispreferably to use a systematic name for each of the offers andproposals. The original filename may be replaced by a systematic namebefore it is saved. The reason is that even though the identity of filesin this system can be precisely maintained, but after the negotiationends, all history files will eventually be transferred to the party.With time passing, there is a substantial chance that the party willlose the information on the dialog files, offers, schedules, andattachments. Due to preexisting errors in naming files, creation dates,and issue dates, the party may again have to decipher the riddle ofinconsistency down the road. The naming method will help the partiesavoid this kind of problem.

In one prospective embodiment of the present invention, the namecomprises first three letters of the party identity together athree-digit number and a type code. “O-ABC-001” means ABC's offer 001while “P-ABC-002” means ABC's proposal 002.

The naming scheme is flexible. It is intended for easy identification,clear indication of source. Surplus information is necessary inresolving identity issues in the future when the file is found in anisolated folder. The submission date is found in the status board. Thenumber may be a serial number generated for all submitted documents oronly for the documents submitted by the party.

To implement the universal serial numbering method, the system needs tokeep a record for tracking the number assignment. The record may be atext file or a database field. The record has zero at the beginning.When an offer is submitted, the status manager reads the last serialnumber string, converts it into an integer, adds it value by one, andconverts back to an ASSCI string. It then uses it and saves it again.The ASCI string is used to formulating the name of the file. Next timewhen another offer is submitted, the status manager will repeat theprocess. In this way, all files can have a serial number in the namestring. If each party uses its own serial number, the system needs tokeep track of the serial numbers for all parties by the same method.

The status manager use a database field to keep track of serial number,it needs to convert integer “1” into “001” before it can be appended tothe file name.

If a party submits a schedule as part of the offer and proposal, it isalso shown on the status table like S-ABC-003-001

In this example, the serial number has two groups of numbers. The firstgroup number is the serial number of the associated offer. The secondgroup of number is a serial number of the schedule. The numbering isflexible. For attachments that are not part of the offer/proposal, theymay be coded using the scheme A-XYZ-09/03/2005-001.

This filename means attachment 001 that was submitted by XYZ on Sep. 3,2005. This file is retrievable by a link on the status board pointing tothe attachment. Again any name is permissible but it is preferable tocontain sufficient information for identifying the attachment clearly.It is not required to spell out all components in the name string.

When a party submits a proposal or offer, the system will write a newentry, which includes the filename, submission date in the status file.It then causes the system to read the file into memory and determine therejection-acceptance status for each of offers and proposals. The ruleis very simple: only the last un-expired offer is a valid offer. A laterproposal cannot operate to reject an earlier offer that has not expired.An agreement is formed only when all parties agree on an offer that hasnot expired within the negotiation period.

The system then optionally sends out the status information to each ofthe parties. It may display all rejected and expired offers andproposals with a mark (such as R or E) and/or with distinctive colors.

Since the status board is constructed in runtime using individual datacomponents, it is easy to add a hot link to point to a file havingfilename O-ABC-001 on the status board. This type of link is usedeverywhere.

7. Email Notification Manager

Optionally, the system contains an email notification manager forsending email upon the happening of an event according to a predeterminescheme. The events triggering the sending of email include:

-   -   1) When a party invites another party to change negotiation        rules and the rules for managing negotiation history files;    -   2) When a party sets up a guest account and invites another        party to join the negotiation or when the system associates two        existing accounts by a project identity;    -   3) When a party submits a dialog, a proposal or offer;    -   4) When an offer expires due to lapse of time;    -   5) When a final agreement is reached;    -   6) When a party quits the negotiation;    -   7) When the deadline for the negotiation is reached without an        agreement; and    -   8) When a party's password is given to another party.

When any of such events happens, the email notification manager willsend an email message to each of the email addresses according to thepredetermined scheme. For different events, the email notificationmanager may use different email addresses as recipients. It is notnecessary to send email to all the parties for each of the events. Emailnotification may be sent to all parties when a party submits an offer,when an agreement is reached, when a party quits, and when negotiationdeadline is reached.

When a party invites a second party to join a negotiation, email is sentonly to the second party. If a party has a main email address associatedwith an account ID, it may also have one or more notification emailaddresses. The recipients of the notification addresses are informed ofthe status of negotiation but preferably may not be allowed to submitoffers and proposals.

After the project is created, the email notification manager will createplural files for storing email addresses, one address for each of theparties. Optionally, all email address lists may be saved in one singlefile if different lists are separated by specific event mark such as<dialogsubmission>, <offersubmission> and <negotiationtermination>. Theemail manager can retrieve the corresponding email address lists foreach of events by using those marks. Obviously, the email addresses maybe stored on a database table with or without usage-flag.

The email sent to the account's main email address may contain a hotlink for accessing the dialog board, the status board and all associatedfiles. The recipient at the account's main email address may be promptedto log in to the account before access is allowed. For the CC ornotification addresses, the message may contain the information aboutthe action. Access by multiple persons of a party may be allowed whenthe party distributes the password and login account ID to other people.The server may impose a limitation on the number of simultaneousaccesses.

The implementation of email notification is well known in prior art. ForLinux based server, it may use the sendmail program to send email. Themessage may be prepared and saved in a file or a database field, and themanager reads the file, and sends it using appropriate recipientaddresses. The manager may use a series of conditional statements forsending email. Any of the particular events listed above may beassociated with a particular email address list and a particular textbody. For the example, the email function in a CGI module may beSendNotification (int event, char [ ] textbody, char [MAX][ ] address) {. . . }, where the address contains a list of email addresses, which isread from a file or constructed in runtime. When an event happens, aninteger variable is assigned with a value (for example, 1 forinvitation, 2 for invitation for change rule, 3 for updating dialogboard, 4 updating the status board, and n for termination ofnegotiation). On the basis on the integer value, the system opens andreads the right text body into the textbody and reads the emailaddresses from the associated file or relevant section of the file. Itthen calls the above function and has mail sent. The email text maycontain a hot link to the login page.

In one prospective embodiment of the present invention, the generalsteps for sending email are as follows:

-   -   1) Event happens due to user action;    -   2) Read message from a file consistent with the event;    -   3) Retrieve correspondent email addresses from a file or        database field for the event;    -   4) Process the message body and, if necessary, add a link; and    -   5) Send the email message to the recipients in the list.

Sometimes, email is not sent until a certain action takes place withouthuman action. For example, when all parties are inactive in an entirenegotiation period, and negotiation ends as a result of expiration oftime, the server needs to check whether negotiations are terminated forlapse of time. The action of searching expired negotiation projectsshould be scheduled to take place around midnight each day, and themessage manager should finish sending out such messages before the startof next work day. Such scheduled email may be sent in a Linux machine byusing cron software component.

III. The Use of the Negotiation System A. Formal Negotiation

This negotiation method is intended for formal negotiation. By usingthis method, a party can tender only offer and counteroffer. There is noroom for submitting a proposal for discussion.

After a project is created, the first party may request the system toassociate its account with one or more negotiation parties under theproject identity. In the alternative, the first party may create a guestaccount for each of the negotiation parties. After the access privilegeis granted to all negotiation parties and account security is in properorder, the parties are ready to negotiate.

A first party starts drafting an agreement and, upon finishing it,submits it to the status board for the second party to consent. Thesystem then displays the offer, preferably by using a systematic name,on the status board. The file is saved in the project folder or databasetables. If the second party logs in and expresses its consent bysubmitting an e-signature, an agreement is reached. A valid agreement isformed only when all the parties express affirmative consent to an offerthat has not been rejected, nor expired.

If the second party does not want to act, it may log out the serverwithout killing the pending offer of the first party. If the secondparty writes an entry in the dialog board without submitting an offer,system will prompt the second party to indicate if it rejects the offeron the status board (not shown in FIGS). In other words, the secondparty has an option to reject or not reject the offer when it only sendsmessage to the dialog board when it does not submit its own offer orcounteroffer. This allows the parties to keep pending offer for furtherconsideration. After the second party takes its action, the first partywill see the action of the second party and takes its action again.

Before the offer is accepted and rejected, the system marks it as activeand valid using a distinctive color and notation on the status board. Ifthe second party rejects the offer, the second party has on option tocreate its own counteroffer using the drafting resource or ordinary wordprocessor and submits it, preferably, with an e-signature. If the firstparty agrees on the counteroffer, an agreement is reached. If the firstparty rejects the counteroffer of the second arty by tendering its owncounteroffer, no agreement has formed. The parties may repeat theprocess until both parties arrive at an agreement or the time period fornegotiation expires. When an agreement is formed, the system will make acopy of the final agreement for permanent record.

Only the last offer that has not been rejected and has not expired ismarked as an active/valid offer. All unaccepted offers other than thelatest offer are marked as rejected offers. Expired offers are marked asexpired offers. If the status board has only expired offers, the systemwill not allow a party to accept an expired offer to form an agreement.A party may reactivate a rejected offer by resubmitting it foracceptance by the other party. The submitting party can do so by openingthe rejected or expired offer, moving it to the entry space for thecurrent day under in its own column. The renewed offer gets a newsystematic name. The status board may be designed to allow a party tomove any of the rejected and expired offers to the current day only foritself. In the alternative, the party may open any of the rejected andexpired offers, edit it and save it on the client machine, and resubmitit to the status board.

During the negotiation process, any of the parties may enter a messagein the negotiation dialog board to discuss any issues. If the partiesset the negotiation rule that allows party to overwrite governing rulesat the time of submission, the party may enlarge or shorten the timeperiod for acceptance. The system keeps track of the expiration day forsuch special offers.

If the parties have chosen to maintain negotiation history files, thesystem will copy and save a copy of negotiation history filespermanently for a period of time after the negotiation ends. The historyfiles include all rejected offers, all expired offers, the dialog log,and the file containing status information. The system may pack allfiles in one folder, zip it, make it available for download, or deliverit by email to each of the parties at the end of the negotiation. Theparties may be permitted to download history files within a period oftime.

If the parties have chosen not to keep history files, the system deleteshistory files according to the preference the parties have chosen at theend of each round of talk or the negotiating period. If the parties havemade a special rule on managing history files in the event that thenegotiation breaks up, it will enforce the rule accordingly.

While the discussion is for two parties, the method is equallyapplicable in negotiation by multiple parties. To change the negotiationrules, all party have to agree to the proposed rules. An offer may berejected by any of the party who tenders a counteroffer, and anagreement is formed only when all parties agree to an offer that has notexpired within the negotiation period.

B. Informal Negotiation

This method is similar to a discussion forum and is useful in informalnegotiation. According to this method, a party may tender oth offer andproposal. If a party submits a proposal, other parties cannot accept itto form a binding agreement. By using this negotiation forum, the costof negotiation will be so low that resenting proposals for considerationis justified. The parties are informed by the system that a proposal isonly used as a bridge for meeting of mind. Proposals may be used tonarrow the distance between parties in reaching an agreement.Preferably, the system displays proposal and offer on the status boardin conspicuously different icons and colors.

If a proposal is posted on the status board, the other party is expectedto provide feedback, edit it and submit it, or create its own proposal.The second party may submit a proposal for consideration or tender anoffer for acceptance. When a party makes a submission, it indicates inthe submission panel whether it is an offer or proposal.

The system will display the status on the status board accordingly. Ifan offer in status board is rejected, the system marks it as rejectedoffer by using a distinctive color. If a proposal is overwritten by acounter proposal, the system marks it as rejected proposal. Rejection ofa proposal will discourage parties from further considering theproposal.

The negotiation may proceed as follows. After the first party submits aproposal or offer, it then sends a notice to the second party by phoneor an email notice. The second party logs in the server to check foroffer and proposal.

If the submission of the first party is a proposal, the second party mayavoid taking any action, enter a comment in the dialog board, tender itsown counter proposal for simultaneous discussion, or tender its ownbinding offer. If the second party does not want to act, it just logsout the server without killing the active proposal of the first party.The second party may open the proposal, read it and submit a feedback tothe dialog board by using the submission panel. The second party mayalso edit the proposal and submits it as its own counter-proposal. Thismay be possibly viewed as rejection of the pending proposal of the firstparty. The second party may also submit an offer to the status board,and thus by implication reject the first parties' proposal. The partymay set up their own rule allowing the proposal to be furtherconsidered.

If the original submission of the first party is an offer, the secondparty may log out without taking any action, submit a comment to thedialog board without killing the pending offer, submit a comment with anexpress intent to reject the pending offer, submit a new proposal forconsideration without killing the pending offer, or submits acounteroffer to reject the pending offer of the first party.

When the second party makes a submission to the dialog board, systemprompts the second party if it rejects the proposal or the offer on thestatus board. The second party has an option to reject or not rejectpending proposal or offer when the second party merely enters a dialogstatement without submitting offer or proposal. This allows the partiesan option to keep any offer or proposal for further consideration.

After the second party takes its action, the first party again takes itsaction. They repeat the process until an agreement is reached. If thesecond party has provided a counteroffer, the first party may revive itsown proposal for further consideration without killing the counterofferof the second party. After the second party has offered a counteroffer,the first party's proposal will be marked as rejected proposal (however,different effect may be given by using a different rule). A valid offeron the status board cannot be rejected by a subsequent proposal unlessthe party expresses its intention at the time of submission. Thisprecedence rule is useful because considering party of an offer can keepthe offer alive and has a chance to test if the tendering party will bewilling to entertain a different deal (In essential, it would be acounteroffer). It is perfectly acceptable that a party might want tokeep an offer alive but yet wants to explore the room for negotiation.

The parties will repeat the process until an agreement is formed ornegotiation ends. All unaccepted offers are marked as rejected offersand all rejected proposals are marked as rejected proposals. When anagreement is formed or negotiation ends, the system will take care ofhistory files according to governing rule as in the formal negotiationcase.

The negotiation forum may be used as real time negotiation. A plan forreal time negotiation may be facilitated by scheduled arrangement,telephone notification, and email notification. Each of the parties maybe informed of the date and time for the negotiation. Each of theparties is requested to prepare its own documents for the review byother parties. During the negotiation, all parties can review thedocuments of other parties, and express its position to accept or rejectproposals and offers of other parties.

The system will enforce history files according to its own rule. Thehistory files include all rejected/expired offers, all rejectedproposals, the dialog log file, email address lists, and the filescontaining the status information. If the project files are stored indatabase, the server eventually needs to retrieve them and save them infiles in a folder. They may be archived as one zip file.

While the above examples are provided for two parties, it is obviousthat the method is useful in negotiation by multiple parties. To changethe negotiation rules, all party have to agree on the change.

An offer may be rejected by any of the party's counteroffer and anyparty's express intention of rejection. Proposal itself will not serveto reject pending offer unless an intention is expressed at the time ofsubmission. An agreement is formed only all parties agree on a validoffer that has not expired within the negotiation period.

It should be pointed out the rules are tentative. For informalnegotiation, there are no formal rules. The governing rules are whateverthe parties agree.

C. Formal and Informal (Dual-Mode) Negotiation

The negotiation forum is particularly useful in dual-purposenegotiation: internal negotiation and external negotiation. If a partyin litigation wants to tender an offer of settlement, its attorney andall decision-makers of the first party need to draft an offer that isacceptable and approved by the decision-makers. In the first phase, theattorney of the first party drafts a proposal for discussion and postsit in the status board. Negotiation will proceed until thedecision-makers reach an agreement on the terms of the offer. Theattorney then logs into a different account, which has a negotiationproject with the second party, which is an adversarial party. Thenegotiation proceeds as a formal negotiation. If the offer is accepted,the negotiation ends.

If the second party rejects the offer and tenders a counteroffer, theattorney of the first party presents the counteroffer to thedecision-makers of the first party in informal negotiation. If thecounteroffer is acceptable to all the decision-makers, the attorney logsin the external account again and expresses the consent of the firstparty to the counteroffer. The negotiation ends.

If the decision-makers do not agree on the counteroffer, the furthernegotiation among the decision-makers may reach a new counteroffer forthe second party. This process of reviewing counteroffers by thedecision-makers, drafting a new counteroffer by the decision-makers,tendering the counteroffer to the second party, rejecting thecounteroffer by the second party, and receiving an newer counterofferfrom the second party may be repeated again and again until thenegotiation ends or an agreement is finally reached.

Such a negotiation forum can reduce negotiation costs and shortennegotiation cycles. For the safety of parties' information, the twoservers may be hosted in two different machines at two differentlocations: the machine hosting the internal negotiation may becompletely controlled by the party or a credible commercial vendor. Itis desirable that an independent party should administrate the serverthat hosts the negotiation between two adversarial parties.

Appendix A

-   create table users(-    id int insigned auto_increment primary key,-    username varchar(20) not null unique,-    password varchar(20) not null,-    email varchar(50) not null unique,-    firstname varchar(20),-    lastname varchar(20),-    title varchar(4),-    address varchar(50),-    city varchar(20),-    state varchar(2),-    zip varchar(5),-    country varchar(20) default ‘USA’,-    phone varchar(12),-    rank tinyint insigned default 0,-    refer tinyint unsigned default 0,-    created_date datetime,-    logintime datetime,-    warning tinyimt insigned default 0,-    activated char(1) default ‘Y’);

Appendix B

-   create table projects(-    id bigint unsigned auto_increment primary key,-    name varchar(50),-    owner varchar(20),-    description text,-    created_date datetime,-    expired_date datetime,-    password varchar(20),-    lineperpage tinyint unsigned default 25,-    refresh tinyint unsigned default 0,-    notify char(1) default ‘N’,-    type tinyint unsigned default 0.-    offerexpired tinyint unsigned default 0,-    offerexpiredunit tinyint unsigned default 0,-    historyfiles char(1) default ‘O’,-    negotiationmode char(1) default ‘S’,-    activated char(1) default ‘Y’);

Appendix C

-   create table projectmembers(-    prjid bigint unsigned,-    membername varchar(20),-    lineperpage tinyint unsigned default 25,-    refresh tinyint unsigned default 0,-    notify char(1) default ‘N’,-    rank int default 0,-    firstlogin tinyint unsigned default 0,-    PRIMARY KEY(prjid,membername));

Appendix D

-   create table projectboard(-    prjid bigint unsigned,-    membername varchar(20),-    id int unsigned not null,-    dialog text,-    dattachment tinyint insigned default 0,-    filename varchar(255),-    filetype varchar(50),-    type char(1) default ‘O’,-    oattachment tinyint unsigned default 0,-    post_date datetime,-    expired_date datetime,-    offer MEDIUMBLOB,-    PRIMARY KEY(prjid,membername,id));

Appendix E

-   create table offerpoll(-    prjid bigint unsigned,-    offerprovider varchar(20),-    id int unsugned not null,-    member name varchar(20),-    decide tinyint unsigned default 0,-    PRIMARY KEY(prjid,offerprovider,id,membername));

Appendix F

-   create table dialogattachments(-    prjid bigint unsigned,-    member name varchar(20) not null,-    filename varchar(255),-    type varchar(50).-    content MEDIUMBLOB,-    primary key(prjid,membername,id) );

Appendix G

-   create table offerattachments(-    prjid bigint unsigned,-    membername varchar(20) not null,-    id int unsigned not null,-    filename varchar(255),-    type varchar(50),-    content MEDIUMBLOB,-    primary key(prjid,membername,id)-   );

Appendix H

-   create table pendingmemebrs(-    prjid bigint unsigned,-    membername varchar(20) not null,-    realname varchar(50),-    email varchar(50),-    message text,-    primary key(prjid,membername) );

Appendix I

-   create table pendingprojects(-    username varchar(20),-    projid bigint unsigned,-    realname varchar(50),-    email varchar(50),-    message text,-    primary key(username,projid) );

Appendix J

-   create table changeprojectrule(-    prjid bigint unsigned primary key,-    membername varchar(20) not null,-    requestdate datetime,-    closedate date,-    type tinyint unsigned default 0,-    offerexpired tinyint unsigned default 0,-    offerexpiredunit tinyint unsigned default 0,-    historyfiles char(1) default ‘O’ );

Appendix K

-   create table changeprjrulepoll(-    prjid bigint unsigned,-    membername varchar(20) not null,-    agree char(1) default ‘Y’,-    primary key(prjid,membername)-   );

Appendix L

-   create table archivedprojects(-    prjid bigint unsigned,-    archiveddate datetime-   );

1. A negotiation system for at least two parties to negotiate over adocument or a transaction, the system comprising: A negotiation serverhaving a network interface and being connected to Internet; At least twoclient computers, each of the client computers connected to theInternet, being used by one of the at least two parties in negotiation;Meaning for creating a project by using browser at one of the clientcomputers, assigning project code, and providing storage for keepingproject basic information, offers, proposals, attachments, dialog files,and a status files; Means for associating an account with the project orby assigning a guest account; Means for submitting dialog statement andattachment to the dialog board where the dialog is displayed; Means forsubmitting documents, offers, proposal, attachments to the status boardfor display, wherein the offers and attachments are available fordownloading or viewing; Means for the party to indicate whether itaccepts or reject a pending document, offer, or proposal; Mean fordetermining whether an offer has expired, the negotiation ends, and anagreement is reached; Means for changing governing rules on offerexpiration date, the right to override a governing rule, and right toretract a document, offer, or proposal under negotiation; Means forsending email notification to at least one parties upon user action oran natural event; and Means for changing the rules governing negotiationhistory files and enforcing the rule in one of the three ways: deletinghistory files at each round of negotiation, deleting history files atend of the negotiation, and keeping history files for permanent record.2. A computer program product for use in a system, the computer programproduct comprising a computer usable medium having computer readablecode embodied on the medium, the computer program code furthercomprising: code residing in the server for generating web pagecontaining a dialog board, a submission panel and a status board, to berendered on the client computer; code for creating project ID, projectbasic information, project data files, and grating access privilege;code for associating an account with a project or assigning an accountfor use with a project by setting permission or create a project membertable; code on the submission panel for accepting text statement andaccepting files, submitting statements, attachments, and offers andschedules to the server for processing and storage; code on the dialogboard for showing party identity, statements, attachments, andsubmission dates, and for updating, displaying and downloading dialogstatements and attachments; code for determining if an offer hasexpired, rejected, if an agreement has been formed and if the projecthas expired; code on the status board for showing party names, submittedpapers, and submission dates, and for downloading and displayingdocuments, offers, and attachments; code for allowing a party to proposenew rules at start of negotiation or in the middle of negotiation,allowing all parties to vote on proposed rules, if they parties adoptnew rules, writing the newly rules into files or database, and enforcingnew rules; code for allowing parties to select governing rule onmanaging history files, and processing history files in one of the ways:deleting history files at each round of negotiation, deleting historyfiles at end of the negotiation, or keeping history files for permanentrecord. code for sending email invitation to prospective parties forjoining negotiation, sending notice upon user action, or automaticallysending notice to the parties concerning activities in project.